Password Management

The first step for users using the Windows client to access Vitalware is to log in to the server. The familiar Login dialog box allows a user to specify their:

  • username
  • password
  • service to which to connect
  • group to use (optional)

The information entered into the Login dialog box is transmitted to the Vitalware server for authentication. In particular, the username and password are checked against a database containing username and password combinations for all persons who are allowed to access the system. Vitalware itself does not store any username / password pairs but relies on external databases to authenticate users.

These external databases are available through a number of sources:

The traditional Unix user's database consists of a file containing a list of all users who may access the system. The file is located at /etc/passwd. A typical entry looks like:

boris:QB2vbP7yzuNzQ:708:400:Boris Badenov:/home/boris:/bin/bash

Each of the fields in the entry is separated by a colon (:). The list of fields is unimportant for this document, except that the first field contains the username and the second field the password. The password is stored in a one way encrypted format, that is, the password cannot be decrypted (so if you forget your password, your System Administrator cannot tell you what it is and a new password must be set).

When a user logs in to Vitalware, their password is encrypted and checked against the encrypted version stored with their username. If there is a match, the user can then access the system.

The Shadow password file is an extension of the base UNIX password file described above. The Shadow file is located in /etc/shadow. If a Shadow password file is used, the user's password in /etc/passwd is replaced with an x. The encrypted password is then stored in the Shadow file. The permissions on the Shadow file only allow the System Administrator account (root) to read the contents, thus protecting the encrypted password from general access. The Shadow file contains extra fields used to implement password ageing. A typical entry looks like:

boris:QB2vbP7yzuNzQ:15215:1:30::::

Like the /etc/passwd file, the fields are separated by a colon (:) and the first two fields store the username and the associated encrypted password. The third field stores the number of days between 1 January 1970 and the last time the user changed his password. The next two fields contain the minimum number and maximum number of days between password changes respectively. In the example above, user boris must change his password at least every thirty days. If the password is not changed within thirty days, it will expire and a new password must be set next time he logs in to Vitalware. The Shadow password file is available with most versions of Unix, including Solaris and Linux (but not FreeBSD).

One problem with the Unix and Shadow databases is that they are stored locally. Each machine has its own version of the database, so if a user wants to access more than one machine, an entry needs to exist on each machine for which access is required. A nice solution would be to have a master version of the password / Shadow database kept on one machine, and have all other machines contact the master machine when looking up password entries. NIS (Network Information name Service), or YP (Yellow Pages) as it was previously known, provides this functionality. One machine stores the NIS master password / Shadow file and all other machines communicate with the master machine when checking a username / password combination. NIS can also be used in conjunction with the Unix or Shadow files, providing support for both local users (via Unix and Shadow) and global users (via NIS).

NIS not only provides password facilities but may also be used to provide a master version of a wide range of other database files. NIS is available for Solaris, Linux and FreeBSD.

Due to shortcomings in the original NIS design (e.g. password ageing is not possible), a new version of NIS, known as NIS+, was released. Its purpose is the same as NIS except it is more secure and provides extended user attributes (like password ageing).

LDAP (Lightweight Directory Access Protocol) is an extension of the NIS idea. One issue with NIS is that it requires a Unix server. It does not provide a general purpose interface that may be used by non-Unix systems. LDAP addresses this problem by implementing a general purpose database (directory) facility that may be used to store any sort of information (including Unix password information). It then defines a system independent way of looking up this information, thus allowing any type of system to retrieve (and possibly update) data. An explanation of how LDAP is structured is beyond the scope of this document. LDAP is available via the OpenLDAP project for Solaris, Linux and FreeBSD. A number of other implementations are also available.

LDAP allows password and Shadow information to be stored in its database, via the posixAccount and shadowAccount object classes respectively. When a user logs in to Vitalware, the LDAP database is consulted to determine whether access should be granted and determine whether the password has expired. As with NIS, the local password / Shadow files may still be used to store local accounts, while LDAP is used for global accounts.

Windows provides a local database used to contain user password information (amongst other things). The information is for local accounts only and provides authentication for users accessing the local machine. In this sense it is very similar in functionality to the Unix / Shadow databases (but implemented differently). Windows authentication is available on all versions of Windows.

AD (Active Directory) is the Windows implementation of a general purpose information database (directory). It uses LDAP as one of its access protocols. This means that LDAP may be used to consult the Active Directory database. Active Directory allows password / Shadow information to be stored and retrieved via the posixAccount and shadowAccount object classes respectively. As with LDAP the information stored is for global accounts. AD is provided with Windows Server systems and can be queried by Solaris, Linux, FreeBSD and Windows. The local Windows accounts may still be used to register local users, while AD is used for global accounts.

As you can see, there are a number of alternatives available for registering Vitalware users and their passwords. In general, each institution will have a policy dictating which of these sources should be used for user authentication.

Vitalware implements three mechanisms for determining whether a username / password combination is correct:

The Pluggable Authentication Module, or PAM for short, is available on all version of Unix, including Solaris, Linux and FreeBSD. It is not available on Windows servers. PAM is a flexible mechanism that uses a configuration file to determine what password sources should be consulted to retrieve password / Shadow information. It provides support for the following database sources:

  • Unix
  • Shadow
  • NIS/NIS+
  • LDAP
  • AD

PAM is the most common look-up mechanism used by Vitalware where the Vitalware server is installed on a Unix system.

Services For Unix (SFU), or Subsystem for UNIX-based Applications (SUA) as it is now known, provides password authentication on Windows based Vitalware servers. SFU / SUA is not configurable. It provides support for the following sources:

  • Windows
  • AD

SFU / SUA is the look-up mechanism used by Vitalware on Windows based Vitalware servers.

If a Unix system does not provide support for PAM, then the Traditional look-up mechanism is used. The Traditional system provides support for the following sources:

  • Unix
  • Shadow

Traditional support is only provided where institutions elect to not use PAM support. In other words, very rarely!